系列：從現場踩坑到 AI 工具 — IT Diagnostic Agent 開發實錄

一個很小的證據

兩個 GitHub Issue，來自兩個互不相識的陌生人。

兩個都是用繁體中文寫的。

tskerpnext 寫：「已修正。原因是：在設定視窗裡切到 Gemini 分頁並儲存 API Key 時……」
kuang1963 寫：「Ollama 沒有開啟 CORS 跨網域存取……」

這件事我一開始沒特別注意，直到寫這一章的時候回頭看。

在 GitHub 上，用繁體中文開 Issue 不是預設行為。 GitHub 的介面是英文，開源社群的慣例是英文，而且用英文能讓更多人看到、更容易被搜尋到。

選擇用繁體中文寫，通常意味著：他判斷這個專案的作者是華文使用者，而且用中文溝通比較準確。

這是我目前手上，關於「這個工具吸引到什麼人」最直接的證據。

（而根據 Day 27 的盤點，這兩位也正好是我唯一有硬證據的兩個真實使用者。兩個使用者，兩個用中文。樣本很小，但一致性是 100%。）

這個工具一開始就是繁中的

Day 08 講過，這不是疏忽，是刻意的決定。

第一版沒有英文。整個介面、所有決策樹節點、所有 Runbook 步驟，全部繁體中文。

英文是後來才加的，而且加的時候我發現有三十幾處中文寫死在 HTML 裡——因為我從來沒預期要支援其他語言。

那個「沒預期」本身就是答案：我做這個工具的時候，心裡想的使用者就是看繁體中文的人。

為什麼是繁體中文

回到 Day 03 講過的一個現象：華文 IT 圈的知識，大多存在「人」身上，不在文件裡。

英文圈的 SRE 社群有成熟的 Runbook 文化。Google、Netflix、Atlassian、PagerDuty 都公開分享過他們的 Runbook 設計。收到告警 → 打開對應 Runbook → 按步驟處理。

而我在東南亞管過的幾個廠，狀況是：前任 IT 離職，下一任花三個月才搞清楚網路架構是怎麼設計的。

這個落差不是因為華文 IT 工程師比較不專業。 是因為：

1. 工具與文件的語言門檻

大部分的 IT 診斷資源、最佳實踐、疑難排解文件，第一手都是英文。

一個現場維護人員如果英文不夠好，他要跨過的不只是技術門檻，還有語言門檻。而在故障當下，那個語言門檻的成本會被放大——你沒有時間邊查字典邊排障。

2. 沒有時間寫文件的文化

「每天都在救火，哪有時間寫文件？」這是我問過的 IT 同行給我最多的答案。

而如果連中文文件都沒時間寫，那用英文寫更不可能。

3. 工具都預設你懂英文

這是最實際的一點。市面上的 IT 工具、ITSM 系統、知識庫平台，繁體中文支援通常是二等公民——介面翻譯得很勉強，說明文件是機器翻譯，社群討論全是英文。

於是形成一個循環： 沒有好的中文工具 → 中文使用者用得很勉強 → 沒有中文的使用回饋 → 沒有人做好的中文工具。

東南亞台商這個特定的市場

我的實際工作場景是台灣、越南、柬埔寨。這裡有一個很具體的市場結構：

海外台商工廠的 IT 現場，語言分層是這樣的：

而一個診斷工具要真的能用，它必須讓中間那一層能操作——因為現場出問題時，第一個到的人通常是他們。

這也是為什麼「英文版」的優先度比我原本想的低。 因為對在地技術人員來說，英文和繁中都不是母語。真正該做的是越南文和高棉文，而那是更後面的事。

但至少繁體中文能讓台籍 IT 主管看懂並且改得動決策樹的內容（這就是 Phase 3 那個表單編輯器存在的理由）。

主管用中文寫節點，在地人員照著點。 這是這個工具在這個市場的實際使用形狀。

一個誠實的限制：我不知道這個市場有多大

上面講的都是我觀察到的需求形狀。但我要把界線畫清楚：

我沒有這個市場的規模數據。

• 台灣有多少家企業的 IT 部門會用這種工具？不知道。
• 海外台商工廠有多少？我知道很多，但沒有數字。
• 這些人裡有多少會為這種工具付錢？完全不知道（Day 28 已經承認了）。

我有的是：二十年在這個環境裡工作的體感，加上兩個用中文開 Issue 的陌生人。

體感和兩個樣本，不構成市場驗證。

我在這篇文章裡能誠實主張的是：這個需求存在，而且供給不足。 至於這個需求能不能支撐一個產品，我不知道。

「被忽略」不等於「有商機」

這一點我想特別講清楚，因為它是一個很容易犯的推理錯誤。

「這個市場被忽略了」聽起來像一個機會。但它也可能意味著：

這個市場被忽略，是因為它不值得做。

可能的原因：

• 規模太小，做出來養不活團隊
• 付費意願低（IT 工具在很多華文企業裡被視為成本，不是投資）
• 客製化需求太高，無法規模化（Day 28 那個代價 2）
• 大廠算過了，覺得不划算

我不能因為看到一個空缺，就假設那個空缺是別人的疏忽。 有時候那是別人算過之後的選擇。

用 Day 13 的測試來問：如果我知道「這個市場被忽略是因為不值得做」，這會改變我做什麼嗎？

會。如果是那樣，我應該把這個工具當成一個開源貢獻來維護，而不是一個商業計畫來投資。

而這兩條路我目前都還開著。 因為我沒有足夠的證據去關掉任何一條。

那繁體中文到底是什麼

如果不談市場規模，繁體中文支援對這個工具的意義是什麼？

我的答案是：它是差異化，不是加分項。

差異化和加分項的區別：

• 加分項 是「有更好」。介面漂亮一點、動畫順一點、多幾個模型選項。
• 差異化 是「沒有就不是同一個東西」。

一個沒有繁體中文的 IT 診斷工具，對一個在越南廠區、英文普通、正在處理斷網的台籍 IT 主管來說，不是「比較差的選項」，是「用不上的選項」。

這跟 Day 19 那條「資料落地是否決條件」是同一個結構：否決條件不能用加分來補償。

一個功能更強但只有英文的工具，不會因為功能強，就變得能在那個現場用。

結構化地看這件事

核心 vs 外部
繁體中文是核心（它決定了誰能用），不是外部的本地化工作。

而我當初把它做成核心的方式很簡單：我根本沒想過要支援別的語言。 那個「沒想過」讓它從一開始就是核心，而不是後來貼上去的一層。

（代價是 Day 08 那三十幾處寫死的中文。但那是實作代價，不是定位錯誤。）

已成立 vs 假設

可控 vs 不可控
我控制不了這個市場有多大。
我控制得了：這個工具的繁中品質是不是真的好用、而不是翻譯過的。

而那是我唯一有絕對優勢的地方——因為那些節點是我用母語、用二十年的現場經驗寫出來的，不是翻譯出來的。

今天的反思

我原本想把這篇寫成「這裡有一個被忽略的市場機會」。

寫的過程中我意識到我沒有資格這樣寫——因為我沒有市場數據，只有體感和兩個樣本。

所以這篇最後變成了：這個需求存在，供給不足，而我不知道它值不值得做成生意。

但有一件事我很確定：那些決策樹節點是我用母語寫的。

不是先用英文想好再翻譯，不是照著英文文件整理，是我腦子裡二十年的排障經驗，直接用中文寫出來。

這種東西沒有辦法被翻譯出來，只能被寫出來。

而它值多少錢，我還不知道。

明天預告： 最後一篇。三十天寫完，我要回頭看看這一路留下了什麼——包括那些沒解決的、還沒驗證的、和我還沒有答案的問題。

作者：Rich Chang | IT 基礎建設工程師 | 越南・柬埔寨・台灣